I recently got a Toshiba Tecra A10-1HU laptop. This is a series describing my experiences with this hardware using Debian Sid. This one comes without any operating system. So I got a recent testing-netinstall CD-image and ran the installer procedure (in expert mode). Everything went fine and I ended with a shiny Squeeze and kernel 2.6.30. Because I use Sid as my usual system, my first action was a dist-upgrade to Sid. This is what lspci -nn tells:

00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07)
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03)
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 03)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI Controller [8086:2929] (rev 03)
01:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232]
05:0b.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba)
05:0b.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04)
05:0b.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21)
05:0b.3 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev ff)
05:0b.4 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 11)
05:0b.5 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 11)

Things that worked out-of-the-box: Display/Graphics (Intel GMA 4500M HD) The integrated graphics chipset, an Intel GMA 4500M HD, works with the xserver-xorg-video-intel package and the default X.org configuration. No custom /etc/X11/xorg.conf is necessary. The (IMHO non-reflecting?) display runs at 1280 800 at 60 Hz. Cable network device The integrated Intel 82567LM Gigabit Network device works with the e1000e kernel module. No customization was necessary. Touchpad/Trackpoint The notebook comes with the so called Toshiba Dual Pointing Device a touchpad (+2 buttons) and a trackpoint (+2 buttons). Both worked without customization. Energy savings/Suspend/Resume apmd and acpid handle this. No problems yet. Suspend/Resume works. I did not yet test (and I m not sure if I should) hibernate and uswsusp. Webcam The webcam is a CNA7157 model or at least detected as such. The video4linux modules handle it and the cheese application produces pictures. Volume-control wheel It works. Module and package information will follow as soon as I figure them out. Things that needed customization WLAN (Intel WiFi Link 5100) The notebook comes with an Intel WiFi Link 5100 device. It does not work out-of-the-box. Following this article, I ve installed the firmware-iwlwifi package and loaded the iwlagn module. Sound (Intel) For the sound device to work the snd_hda_intel module is necessary. Further the following lines must be added to /etc/modprobe.d/alsa-base.conf

# not sure about the first line, start adding the second only
options snd-cmipci mpu_port=0x330 fm_port=0x388
options snd-hda-intel index=0 model=toshiba position_fix=1

Unsure/Not yet working Temperature sensor After installing the sensors-applet I got two identical temperature displays. I m not sure what they show. Anybody an idea how to examine this? Modem The notebook comes with an internal modem device:

00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07)

From what I read I need hsfmodem or the sl-modem packages. Unfortunately the latest version is not available for amd64 from the archive, although it seems to have been built. Untested I did not yet test

• Bluetooth (icon there, kernel module loaded)
• Firewire (kernel module loaded)
• Card-reader (kernel modules loaded)

Summit This what lspci -k -nn tells about the used kernel modules:

00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
	Subsystem: Toshiba America Info Systems Device [1179:0004]
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
	Subsystem: Toshiba America Info Systems Device [1179:0004]
00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: e1000e
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: uhci_hcd
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: uhci_hcd
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: uhci_hcd
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: ehci_hcd
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: HDA Intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
	Kernel driver in use: pcieport-driver
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03)
	Kernel driver in use: pcieport-driver
00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 03)
	Kernel driver in use: pcieport-driver
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: uhci_hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: uhci_hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: uhci_hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI Controller [8086:2929] (rev 03)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: ahci
01:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232]
	Subsystem: Intel Corporation Device [8086:1201]
	Kernel driver in use: iwlagn
05:0b.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: yenta_cardbus
05:0b.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: firewire_ohci
05:0b.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
	Kernel driver in use: sdhci-pci
05:0b.3 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev ff)
	Kernel driver in use: ricoh-mmc
05:0b.4 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 11)
	Subsystem: Toshiba America Info Systems Device [1179:0001]
05:0b.5 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 11)
	Subsystem: Toshiba America Info Systems Device [1179:0001]

I m back from the conference at Berlin Faktor X - Tag der nat rlichen Ressourcen , a side-conference of the World Resources Forum 2009 in Davos. It was pretty interesting, although the topic is not new. If you don t know it: We are running out of (several) resources. The main topics going through the media are often energy and oil . Well, several metals will become much more problematic much more earlier! So, what is the aim: material-, product- and production-efficiency and recycling/upcycling(/downcycling). One of the topics mentioned at the conference was the IT industry. One of the keywords is green IT - more efficiency through IT, more efficiency by more efficient hardware, better recycling of hardware, . Another point was more efficiency by more efficient software . One of the questions mentioned was how much resources costs a click at google . I think, one can adapt this question to almost every software. We have several software, which is widely used. I ll just mention the apache web-server. Would t it be good to know, that this widely used software won t waste CPU cycles for nothing? So what about a GSoC project checking such often/widely used software for efficiency (besides checking for buffer or heap overflows or NULL pointer dereferences)? Can anybody imagine such a project? What is your opinion?

I always wanted to write a short howto for Debian package maintainers, how to write a manual page in GROFF. This is useful for short documents (for longer documents, docbook/docbook-xsl can be a good choice). I already have written some parts. However, here is the first part of hints. More might follow later. The delimiter in the NAME section The name section is (probably) the only place, where exactly one hypen-minus \- must appear. The hyphen-minus is the delimiter between the command name and one-line description.

.SH NAME
foo-bar \- foos the template foo-what-bar

Typical mistakes regarding paragraphs Using a .PP macro directly following a .SH or .SS macro is useless. This macro should be used between paragraphs:

.SH OPTIONS
The program follows the usual GNU command line syntax, with long options starting with
two dashes ( \-').
.PP
A summary of options is included below.

Options/File descriptions To describe options or files it s usually useful to make use of the .TP macro.

.SH OPTIONS
.TP
.B \-f, \-\-force
Force the execution of the specified command.

.SH FILES
.TP
.I ~/.foobar
Per user configuration file.

To create more than one intended paragraph the .IP macro can be used.

.TP
.B \-f, \-\-force
Force the execution of the specified command.
.IP
This option has no effect in conjunction with \fB\-\-foo\fP.

Avoid hyphenation in URLs/URIs/paths Usually we don t want URLs or URIs to be hyphenated. This can be done using the \% sequence. Typical examples:

A short tutorial is available online at \fI\%http://foo.tld/some/path/here/manual.html\fP.

On a Debian system the complete text of the GNU General Public License
version 2 can be found in the file \fI\%/usr/share/common-licenses/GPL\-2\fP.

Referencing persons and their mail address The common markup is to write the person name in bold letters and the mail address in roman letters is put into angle brackets. It s usually a good idea to mark where the mail address starts and ends. We can use the \& sequence as shown in the following example:

\fBDaniel Leidert\fP <\&daniel.leidert@wgdd.de\&>

I tried to connect my university workstation to the wireless eduroam network on the campus. The workstation was delivered with an Abit AirPace wlan card (probably an Atheros 5006 chipset). The first thing necessary was the ath5k kernel module (my first shot using ndiswrapper didn t work). Both Debian lenny and Ubuntu intrepid-updates provide it. Now there are generally 3 ways to connect to the AP. All making use of wpasupplicant. Further the certificate (may differ for the universities) is necessary. /etc/wpa_supplicant/wpa_supplicant.conf This is described at the sites of my university. It s written in German, but it should still be easy to understand. Let s just mention the snippet for /etc/wpa_supplicant/wpa_supplicant.conf:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=2
ap_scan=1
fast_reauth=1
network= 
	ssid="eduroam"
	key_mgmt=WPA-EAP
	proto=RSN
	pairwise=CCMP
	group=TKIP
	eap=TTLS
	anonymous_identity="anonymous@tu-dresden.de"
	identity="****@tu-dresden.de 
	password= **** 
	ca_cert= /etc/wpa_supplicant/TUD-CACert.pem 
	phase2= auth=PAP 
 

Instead of the script suggested at the site above, you can also use this snippet in /etc/network/interfaces:

auto wlan0
iface wlan0 inet dhcp
	wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

/etc/network/interfaces It is also possible to put the values directly into /etc/network/interfaces:

auto wlan0
iface wlan0 inet dhcp
	wpa-ssid eduroam
	wpa-proto RSN
	wpa-group CCMP TKIP
	wpa-pairwise CCMP TKIP
	wpa-key-mgmt WPA-EAP
	wpa-eap TTLS
	wpa-ca-cert /etc/wpa_supplicant/TUD-CACert.pem
	wpa-phase2 "auth=PAP"
	wpa-anonymous-identity anonymous@tu-dresden.de
	wpa-identity ****@tu-dresden.de
	wpa-password ****

network-manager Here is a screenshot of the authentication dialog. So now everybody at the University of Dresden wanting to use eduroam should hopefully be able to configure this connection on his Debian/Ubuntu system.

Maybe you will observe a changed mouse and keyboard behaviour after updating X.org recently in Debian Sid. Then you will probably discover the warning mentioned in the title in your X.org server log /var/log/Xorg.0.log. The very short and dirty solution to get things working for the moment is to put this into your /etc/X11/xorg.conf:

Section "ServerLayout"
    Option "AutoAddDevices" "off"
EndSection

See the first entry in /usr/share/doc/xserver-xorg/NEWS.Debian.gz and follow the mentioned links for more information. However, the above solution should only be a temporary workaround: Try to migrate things (I will post changes for my system asap).

The recent update to udev 0.140 lead to a system without network access to me. The error messages were:

Running 0dns-down to make sure resolv.conf is ok...done.
Setting up networking....
Configuring network interfaces...
ioctl[SIOCGIFFLAGS]: No such device
Could not get interface  ath0  flags
ioctl[SIOCSIWPMKSA]: No such device
ioctl[SIOCSIWMODE]: No such device
Could not configure driver to use managed mode
ioctl[SIOCGIWRANGE]: No such device
ioctl[SIOCGIFINDEX]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWAP]: No such device
ioctl[SIOCGIFFLAGS]: No such device
wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
/etc/network/if-pre-up.d/wpasupplicant exited with return code 1
SIOCSIFADDR: No such device
ath0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
ath0: ERROR while getting interface flags: No such device
ath0: ERROR while getting interface flags: No such device
Failed to bring up ath0.
done.

It seems, the update added rules to /etc/udev/rules.d/70-persistent-net.rules by increasing the device number and applying the last applicable NAME directive instead of the first one. This lead to the following file here:

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS address =="XX:XX:XX:XX:XX:a7", ATTRS type =="1", NAME="ath0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS address =="XX:XX:XX:XX:XX:18", NAME="eth0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS address =="XX:XX:XX:XX:XX:XX", NAME="eth1"
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR address =="XX:XX:XX:XX:XX:18", ATTR type =="1", KERNEL=="eth*", NAME="eth2"
# PCI device 0x168c:0x0013 (ath_pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR address =="XX:XX:XX:XX:XX:a7", ATTR type =="1", KERNEL=="ath*", NAME="ath1"

So the devices created were eth2 and ath1 but /etc/network/interfaces contained entries for eth0 and ath0. So fixed /etc/udev/rules.d/70-persistent-net.rules and rebooted. <rant>Is it really necessary to break network access with an update???</rant> Update I forgot this one: #521521.

Debian- and Ubuntu-packages of bluefish-unstable - the development series of bluefish - for the amd64 architecture are now available.

Now that Lenny has been released I ve updated some machines and found just one flaw. There is a cvsd installation, which has been extended with an OpenSSH server. After the upgrade the server refused the connection. Enabling debugging output showed:

sshd[...]: fatal: ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: security_getenforce() failed

in the log. Searching the web a bit revealed, that the CHROOT now needs a mounted /proc. Done and everything works :)

Yesterday I stumbled about files and dead symlinks left in /usr/lib/python2.3/site-packages/ on my Sid box. These files/symlinks seem to have been shipped/created(?) by:

python-ldap python-cairo python-crypto kiki python-foomatic python-mysqldb
python-logilab-common python-egenix-mxtools python-numarray python-pygresql
python-imaging-sane python-imaging python-xml python-reportlab

Deleting /usr/lib/python2.3 (dpkg -S didn’t show any package relationship nor did I find something in /var/lib/dpkg/info/) and reinstalling the above mentioned packages did not recreate the files/symlinks. So it seems the directory can be safely removed. Maybe I missed some announcement or one (or more) packages need to be fixed. No time to examine it atm. Update This is known as Debian bug #409390. Thanks to Josselin Mouette for the information.

Ok, shit sometimes also happens to Debian users. Now I read a lot of FUD, flames, arrogant claims and much more bad things, including blaming of downstream in general. Well, Debian maintainers are NOT upstream authors. Maintainers often care about a lot more than just 1 package. Now I wonder if one can really expect, that maintainers know the source code of their packages as good as upstream authors do? Is this, what the user or the Debian project expects from a package maintainer? I agree, that this would be the ideal situation. But how realistic is it, if one maintains 10, 20 or more packages? Normally users report us issues. We take a look at the source, try to catch the issue, track it down and fix it. And IMHO in almost all cases this is enough and it lets us handle several packages. And maybe this is also, what happened here. The maintainer got a report, tracked it down and tried to fix it. It seems, he posted it to the openssl-dev list, which is to my reading considered for such questions, and got a positive response. And with fixing it, he made a horrible mistake. But apparently it also seems, that the question had been discussed earlier more than just once (I wish, the OpenSSL guys would have created the FAQ entry earlier). I don’t want to blame the maintainer for doing this mistake. We are humans. But do we need another instance, that (periodically) checks (probably only Debian-specific) patches/changes to security relevent software or do we need different requirements for maintainers of such software [1] or should we simply archive this under “Shit sometimes happens … even to Debian users”? [1] Consider gnupg which is currently almost unmaintained. It also has Debian specific patches applied and I wonder, which skills the new maintainer should or must(?) have (IIRC this question was raised in the linked threads too)?

I’m sorry for any inconvenience you had yesterday or today trying to access my web services. But I had to perform some long standing maintenance tasks. The service is now running again. If you still observe problems, please don’t hesitate to tell me.

Because my diploma exams are getting nearer, I have to reduce my contribution to the Debian project for the next two months (up to mid/end of May). There is fortunately currently not much to do for me and also no need to NMU my packages. But please read the following notes, if you (still) think there is a reason for a NMU: GCC 4.3 transition Done. All related packages have been fixed. My sponsor just needs to upload psicode to fix the last outstanding bug. PS: Also the build-twice-in-a-row release goal will be reached by the upload of the apbs update by my sponsor. gfortran transition Almost done. mpqc already reached the buildds. ghemical has been uploaded, but waits for mopac7 and libghemical, which are in NEW because of the new library names. apbs and psicode already have been transitioned. Other bugs Ok, I’ve closed almost all relevant bugs in my packages. There are a few outstanding bugs that should be examined for Lenny and can be fixed in NMUs - preferable via delayed NMU queue and an information to the debichem group:

#420795: chemical-mime-data: Unknown media type in type ‘chemical/x-*’

Upstream bug tracker for shared-mime-info contains some more information, how to deal with this. Patches/ideas welcome.

#438694: gabedit: Crashes when loading any XYZ format file

Looks tricky. Maybe an OpenGL issue related to some video card drivers. Not sure.

#442223: openbabel: some connect information lost when convert from pdb to txyz

Nothing examined yet to solve this bug.

#464867: extrema: conflicts with psi3 package

Hope, my team will cover this asap.

#465723: mopac7 — please do not use g2c.

There is currently a workaround using f2c to solve this bug. But MOPAC7 has been written in FORTRAN and we can use gfortran and drop f2c completely. See the report for more information. This is something I would like to see in Lenny.

For the xmlto package it was planned to add the dblatex toolchain for PDF/PS/DVI creation because passivetex will very probably never have a comeback in Debian and docbook-xsl/fop is not fully main and cannot create DVI output. In the case you want to help, feel free to add this feature by NMU to experimental (maybe with version 0.0.21~dblatexX.Y). A first patch is available in bug report #416622. New upstream releases It is possible that there will be a new upstream release for docbook-xsl in the near future. DO NOT consider uploading it by NMU if you did not test it! This upcoming release ships manpage stylesheets, that have been rewritten in large parts. So regressions can be expected. Fortunately Michael Smith and me agreed, that we should test it carefully, before the release is done. Unfortunately I will not have the time to do it. So if you consider uploading it, please get in contact with Michael (xmldoc) and offer your help testing it. He added (and I hope, many Debian packagers and packaging groups will like that) some kind of regressions tests. These tests build the manpages from several Debian packages: e.g. samba, apt, aptitude, git, fglrx and some more. There are further some new supported features, that should be added to the manpage example shipped with the Debian package. I also planned to split the source package (atm, docbook-xsl and docbook-xsl-doc tarballs are merged together for Debian) as soon as docbook-xsl-ns is packaged - which I wanted to do with the next upstream release. So consider all of the above notes if you plan an NMU to upload a new upstream release and in question, mail me and wait for my answer (which will need some days). In all other cases, new upstream releases should be easier to handle. ITPs All my ITPs are delayed. However if you plan to still upload one of these packages, you should consider the following notes:

docbook-xsl-ns

See the above note about docbook-xsl and the source package split.

html-xml-utils

Already in a good shape, but I sent upstream some patches to improve the manpages. Version 4.6 of the html-xml-utils should contain these patches and this version should be uploaded into Debian. With this version, Bert Bos will probably also decide, which prefix will be used for the binaries (they have very generic names atm; the prefix will probably be hx- or hxu-). Waiting for this releaes therefor is IMHO a good choice.

DocBook 5

I already found a problem that need to be addressed in the package: Where to install its catalog? You will see, that there is already a catalog file in /usr/share/xml/docbook/schema/dtd/ shipped by the docbook-xml. Now I’m not sure, what to do here. Upstream ships one catalog file for all supported schemas (RNG, DTD, W3C schema and schematron), so maybe the catalog file can go into /usr/share/xml/docbook/schema/. Really not sure atm. The answer to this question might affect the Debian XML policy and should be made carefully.

QA work/fixes Several lintian warnings have already been fixed in the SVN repositories used for my packages but have not yet been uploaded. I really only plan to reduce my work during the preparation and the exams. So whatever you do, please try to make it easy for me to continue my packaging work after the exams :)

pbuilder with default settings will fail to build a package depending on sun-java5 or sun-java6, because the license needs to be accepted first. Now some time ago I saw a patch for pbuilder itself to “fix” this, but for the time beeing I used to set DEBIAN_FRONTEND to readline in my pbuilderrc. But today Michael Koch came up with much better suggestions: Preset the debconf value in the CHROOT and save it. It’s pretty easy:

$ sudo pbuilder login --save-after-login
# echo "sun-java5-jdk shared/accepted-sun-dlj-v1-1 boolean true"   debconf-set-selections
# echo "sun-java6-jdk shared/accepted-sun-dlj-v1-1 boolean true"   debconf-set-selections
# exit

and voila, problem solved. Thanks to Michael for the tip.

I promised it some time ago and now it has been done: Debian packages for the development tree (1.1 series) of Bluefish are ready for Debian users (i386 only). The packages can be installed along with the stable version, so you can safely test new features and give us feedback and bug reports. NOTE: The packages cannot be (re)built on Etch, because debhelper version 5.0.57 or higher is necessary. I will fix this part of debian/rules soon, so it can be (re)built on Etch too.

Some days ago I wrote down my experiences with packaging docbook-defguide. The main (remaining) issues I mentioned were the resources and the time the package needs to build. Even on an AMD X2 4600+ with 6GB of RAM it needs 7-8 hours. Today I met with Torsten Werner. He mentioned, that there are some move JVMs I could try. So I tested alternatives to GIJ this night. I found this short summary about free JVMs, which was some kind of interesting. I began with cacao, which seemed to be fast, but it was killed very early in the build process with an java.lang.OutOfMemory error. Even playing around with the -Xms and -Xmx switches in buildtools/saxon.sh did not help. So I dropped cacao from the list. Seems both cacao and kaffe create similar problems here and are not suitable for building the package. Second alternative I tried was sablevm. It directly throw out some warnings or errors so I directly dropped it too. Next JVM was jamvm. But it was as slow as GIJ. So I dropped it from the list of alternatives too. Then I found an interesting statement in the article I linked somewhere above. The author said, that his perfomance test time with GCJ/GIJ reduced from 433 to 9 seconds, when he compiled his application into a native executable. So I took a fast look through the docbook-defguide build dependencies and found, that Debian already provides a natively compiled Xerces package libxerces2-java-gcj. But there were no packages for libsaxon-java, libxml-commons-resolver1.1-java and docbook-xsl-saxon. So short and dirty: I downloaded the source for these packages, added the necessary stuff to get natively compiled packages too, built and installed them. Fortunately packages with native code already exist (JAXP 1.3 and Xerces) for their dependencies. And what should I say: Now building the TDG needs less then 512MB RAM and it builds in around an hour … even on my system. I will ask the Debian Java maintainers to add -gcj packages for Saxon and XML-Commons and fix my own docbook-xsl-saxon package. This will hopefully help maintaining docbook-defguide.

Ok guys. After spending several hours of this weekend to package the latest release of Norman Walshs DocBook: The Definitive Guide, I’m now proud to tell you: It’s done! I was able to build the package with a free Java engine (GIJ) so docbook-defguide can stay in main. However, it was some kind of disappointing: Sun Java needs an hour and a maximum heapsize of 512MB to build the package on my system. GIJ needs 16 hours and a maximum heap size of 1GB to build. kaffe, which I tried too, fails much earlier than GIJ with a maximum heap size of 512MB. So I decided against it and for GIJ. If you know of a way to speed up the build process (besides the possibility to buy a faster system … except you want to make it your christmas or birthday present for me *g*), don’t hesitate to tell me. The packaging files are in the Debian XML/SGML groups SVN repository. However, expect the package in your Debian repository soon (guess, my sponsor wants to rebuild it, which may need another 1x hours :)). Update Ardo van Rangelrooij kindly offered to build the package on an AMD X2 4600+ with 6GB. The build time decreased to at least 7-8 hours. The package will be uploaded to the Debian archive within the next days.

Now that I discovered this nice flag I checked a few of my packages. It works nice for the gnome-chemistry-utils application packages. Unfortunately libgcu0 does not benefit from the flag because of libtool bug #347650. However there is an appreciably difference in the dependencies for the plugin and application packages, where the amount of dependencies decreased. For example compare the old

Depends: iceweasel   iceape-browser   xulrunner, libart-2.0-2 (>= 2.3.18),
libatk1.0-0 (>= 1.20.0), libc6 (>= 2.6.1-1), libcairo2 (>= 1.4.0), libgcc1 (>= 1:4.2.1), libgconf2-4 (>= 2.13.5),
libgcu0 (<< 0.9), libgcu0 (>= 0.8), libgl1-mesa-glx   libgl1, libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.14.0),
libglu1-mesa   libglu1, libgnomecanvas2-0 (>= 2.11.1), libgnomeprint2.2-0 (>= 2.17.0),
libgnomeprintui2.2-0 (>= 2.17.0), libgnomevfs2-0 (>= 1:2.17.90), libgoffice-0-4 (>= 0.4.2),
libgsf-1-114 (>= 1.14.7), libgtk2.0-0 (>= 2.12.0), libgtkglext1, libice6 (>= 1:1.0.0), libnspr4-0d (>= 1.8.0.10),
libopenbabel2, liborbit2 (>= 1:2.14.1), libpango1.0-0 (>= 1.18.3), libsm6, libstdc++6 (>= 4.2.1), libx11-6,
libxml2 (>= 2.6.27), libxmu6, libxt6, zlib1g (>= 1:1.2.3.3.dfsg-1)

and the new Depends field for gcu-plugin:

Depends: libc6 (>= 2.6.1-1), libgcc1 (>= 1:4.2.1), libgcu0 (<< 0.9),
libgcu0 (>= 0.8), libglib2.0-0 (>= 2.14.0), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0),
libnspr4-0d (>= 1.8.0.10), libstdc++6 (>= 4.2.1), libx11-6, libxml2 (>= 2.6.29), iceweasel   iceape-browser  
xulrunner

As another example bluefish now (the next upload) really only shows the necessary dependencies. Compare the current:

Depends: libart-2.0-2 (>= 2.3.18), libaspell15 (>= 0.60),
libatk1.0-0 (>= 1.20.0), libbonobo2-0 (>= 2.15.0), libbonoboui2-0 (>= 2.15.1), libc6 (>= 2.6.1-1),
libcairo2 (>= 1.4.0), libfontconfig1 (>= 2.4.0), libgconf2-4 (>= 2.13.5), libglib2.0-0 (>= 2.14.0),
libgnome2-0 (>= 2.17.3), libgnomecanvas2-0 (>= 2.11.1), libgnomeui-0 (>= 2.17.1),
libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libice6 (>= 1:1.0.0), liborbit2 (>= 1:2.14.1),
libpango1.0-0 (>= 1.18.2), libpcre3 (>= 6.0), libpopt0 (>= 1.10), libsm6, libx11-6, libxcomposite1 (>= 1:0.3-1),
libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3 (>= 1:4.0.1), libxi6, libxinerama1,
libxrandr2 (>= 2:1.2.0), libxrender1

to the “upcoming” Depends field:

Depends: libaspell15 (>= 0.60), libc6 (>= 2.7-1), libglib2.0-0 (>= 2.14.0),
libgnomeui-0 (>= 2.17.1), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libpango1.0-0 (>= 1.18.3),
libpcre3 (>= 6.0)

Nice result. I should check (my) other packages too :) Maybe that’s also something for debichems TODO list.

I’m currently evaluating Olivier Sessinks jailkit to maintain a small cvsd CHROOT with an included SSH server. The cvsd-buildroot command e.g. doesn’t handle the libpam-modules dependency in the CHROOT. So I tried to update the Debian packaging files included in the jailkit source. During this work I found some issues with the build environment - e.g. no DESTDIR support and some other stuff (another user already complained, that there might be problems with the SUID installation part for jk_chrootsh, jk_uchroot and jk_procmailwrapper of the Makefiles). So I began to check and “fix” the Makefiles and the configure script and then sent everything to Olivier. I did not only add the DESTDIR variables. I also made use of built-in rules, common variables (also for implicit rules), … and such stuff to make the Makefiles shorter and easier to maintain. My fault: I tested everything with GNU make. Now Olivier complained, that BSDs make doesn’t work anymore. So we began a short hack session to check for the problems. My first issue: I had to find some BSD make to test it myself. I found it in the freebsd5-buildutils, that contains the freebsd-make command. Then we began to check for incompatibilities and that’s the result:

1. ifdef statements differ in syntax
   • GNU make uses ifdef VAR
   • BSD make uses .ifdef VAR
   solution: We replaced the statement with a construct similar to AM_CONDITIONAL. But we do not use this macro, because it would need to be shipped in aclocal.m4, which is currently not necessary. The code simply sets a variable foo_TRUE to ‘# ‘, if the condition is wrong, or the variable is left empty, if the condition is true:

   if test "x$my_condition" != "xno" ; then
       AC_SUBST([foo_TRUE], [])
   else
       AC_SUBST([foo_TRUE], [# ])
   fi

   FILES = bar
   @foo_TRUE@FILES += foo

2. prerequisite variables differ in syntax
   • GNU make uses $<, $^, $@, …
   • BSD make uses $ .IMPSRC , $ .ALLSRC , $ .TARGET , … (note, that both *SRC variables hold a list of source files)
   Unfortunately both make implementations doesn’t seem to share a variable for the list of prerequisites. So the only solution is to list all prerequisites in the rule again. A variable would be much more comfortable. Maybe one could write a function, that first tests $ .IMPSRC and falls back to $^. Maybe that’s an alternative, but it’s IMHO not a very good solution. We’ve chosen to write down all prerequisites in a rule instead of using a variable. This is a little bit “harder” to maintain, but it works.
3. built-in rules are not shared and do not use the same variables
   • GNU make ships built-in rules to build objects from sources and link them; rules consider CPPFLAGS
   • BSD make ships built-in rules to build objects from sources, but there are no rules to link them; rules do not consider CPPFLAGS
   In the case of GNU make, one can simply write:

   myprog: foo.o bar.o

   and GNU make will automatically create foo.o from foo.c (.c.o:, ditto for bar.o) and at least link myprog (.o:). But BSD make will only create the object files. There is no final link-step. So we had to include the rule to link the program in the Makefile.

Finally we got it and it looks good now. I/We learned a lot of new things (I learnd a lot about BSD make) ;), but it took us 1-2 hours to understand and fix the problems. Here a list of URLs, that might give some more information about the programs, their syntax and limitations:

• GNU make’ manual
• FreeBSDs make
• Autoconf: Limitations of make